However we store some literal values as `Int` in the compiler. As a
result, some Cmm optimizations transformed target 64-bit literals into
compiler `Int`. If the compiler is 32-bit, this leads to computing with
wrong literals (see #24893 and #24700).
This patch disables these Cmm optimizations for 32-bit compilers. This
is unsatisfying (optimizations shouldn't be compiler-word-size
dependent) but it fixes the bug and it makes the patch easy to backport.
A proper fix would be much more invasive but it shall be implemented in
the future.
Co-authored-by: amesgen <amesgen@amesgen.de>
Gbp-Pq: Name pr-13096
Hadrian only contains bootstrap plans for previous GHC versions. Add plans for
the current version as well, since we may want to bootstrap hadrian with a
cross-compiled GHC that is of the same version as the GHC we are building here.
Peter Trommler [Tue, 7 Nov 2023 20:47:24 +0000 (21:47 +0100)]
[PATCH] PPC NCG: Generate clear right insn at arch width
The clear right immediate (clrrxi) is only available in word and
doubleword width. Generate clrrxi instructions at architecture
width for all MachOp widths.
Previously `ghc-prim`'s atomic wrappers used the legacy `__sync_*`
family of C builtins. Here we refactor these to rather use the
appropriate C11 atomic equivalents, allowing us to be more explicit
about the expected ordering semantics.
GHC 8.10 fails to build on armel with the following error:
LLVM ERROR: unable to allocate function argument #8
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Program arguments: llc-12 -O2 -enable-tbaa -relocation-model=pic -mcpu=arm7tdmi -mattr=+soft-float,-vfp2,-vfp2sp,-vfp3,-vfp3d16,-vfp3d16sp,-vfp3sp,-fp16,-vfp4,-vfp4d16,-vfp4d16sp,-vfp4sp,-fp-armv8,-fp-armv8d16,-fp-armv8d16sp,-fp-armv8sp,-fullfp16,-fp64,-d32,-neon,-crypto,-dotprod,-fp16fml,-bf16,-mve,-mve.fp,-fpregs,+strict-align /tmp/ghc5537_0/ghc_6.bc -o /tmp/ghc5537_0/ghc_7.lm_s
1. Running pass 'Function Pass Manager' on module '/tmp/ghc20177_0/ghc_6.bc'.
2. Running pass 'ARM Instruction Selection' on function '@"stg_gc_f1$def"'
`llc-12' failed in phase `LLVM Compiler'. (Exit code: -6)
make[3]: *** [rts/ghc.mk:325: rts/dist/build/HeapStackCheck.o] Error 1
This patch enables a few native 64-bit integer instructions
on x32 which are available on this architecture despite using
32-bit pointers. These instructions are present on x86_64 but
not on x86 and ghc checks the size of (void *) to determine
that. This method fails on x32 since despite using 32-bit
pointers and hence sizeof(void *) == 4, it still uses the
full x86_64 instruction set and software-emulated variants
of the aforementioned 64-bit integer instructions are
therefore not present in the toolchain which will make ghc
fail to build on x32.
See: https://ghc.haskell.org/trac/ghc/ticket/11571
Jani writes: The D16 part was Debian/Ubuntu specific, IIRC we define hardfloat
in that particular variant (16 double registers) or we had a different naming
for some reason.
GCC 14 on aarch64 rejects the C code written by GHC with this kind of
error:
error: assignment to ‘ffi_arg’ {aka ‘long unsigned int’} from ‘HsPtr’ {aka ‘void *’} makes integer from pointer without a cast [-Wint-conversion]
68 | *(ffi_arg*)resp = cret;
| ^
Add the correct cast.
For more information on this see:
https://fedoraproject.org/wiki/Changes/PortingToModernC
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Gbp-Pq: Name fix-gcc14-ffi_arg
[PATCH] llvmGen: Align objects in the data section
Objects in the data section may be referenced via tagged pointers.
Thus, align those objects to a 4- or 8-byte boundary for 32- or 64-bit
platforms, respectively. Note, this may need to be reconsidered if
objects with a greater natural alignment requirement are emitted as e.g.
128-bit atomics.
Peter Trommler [Tue, 7 Nov 2023 20:47:24 +0000 (21:47 +0100)]
[PATCH] PPC NCG: Generate clear right insn at arch width
The clear right immediate (clrrxi) is only available in word and
doubleword width. Generate clrrxi instructions at architecture
width for all MachOp widths.
Previously `ghc-prim`'s atomic wrappers used the legacy `__sync_*`
family of C builtins. Here we refactor these to rather use the
appropriate C11 atomic equivalents, allowing us to be more explicit
about the expected ordering semantics.
Hadrian passes the -DNOSMP flag to GHC when the target doesn't support
SMP, but doesn't pass it to CC as well, leading to the following
compilation error on mips64el:
| Run Cc (FindCDependencies CDep) Stage1: rts/sm/NonMovingScav.c => _build/stage1/rts/build/c/sm/NonMovingScav.o.d
Command line: /usr/bin/mips64el-linux-gnuabi64-gcc -E -MM -MG -MF _build/stage1/rts/build/c/hooks/FlagDefaults.thr_debug_p_o.d -MT _build/stage1/rts/build/c/hooks/FlagDefaults.o -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -Irts/include -x c rts/hooks/FlagDefaults.c -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Winline -Wpointer-arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls -Wundef -fno-strict-aliasing -DTHREADED_RTS -DDEBUG -fomit-frame-pointer -O2 -g -Irts -I_build/stage1/rts/build -DDEBUG -fno-omit-frame-pointer -g3 -O0
===> Command failed with error code: 1
In file included from rts/include/Stg.h:348,
from rts/include/Rts.h:38,
from rts/hooks/FlagDefaults.c:8:
rts/include/stg/SMP.h:416:2: error: #error memory barriers unimplemented on this architecture
416 | #error memory barriers unimplemented on this architecture
| ^~~~~
rts/include/stg/SMP.h:440:2: error: #error memory barriers unimplemented on this architecture
440 | #error memory barriers unimplemented on this architecture
| ^~~~~
rts/include/stg/SMP.h:464:2: error: #error memory barriers unimplemented on this architecture
464 | #error memory barriers unimplemented on this architecture
| ^~~~~
The old make system correctly passed this flag to both GHC and CC [1].
CmmToC: fix CmmRegOff for 64-bit register on a 32-bit target
We used to print the offset value to a platform word sized integer.
This is incorrect when the offset is negative (e.g. output of cmm
constant folding) and the register is 64-bit but on a 32-bit target,
and may lead to incorrect runtime result (e.g. #22607).
The fix is simple: just treat it as a proper MO_Add, with the correct
width info inferred from the register itself.
hs_cmpxchg64 must return a StgWord64, otherwise incorrect runtime
results of 64-bit MO_Cmpxchg will appear in 32-bit unregisterised
builds, which go unnoticed at compile-time due to C implicit casting
in .hc files.
Hadrian only contains bootstrap plans for previous GHC versions. Add plans for
the current version as well, since we may want to bootstrap hadrian with a
cross-compiled GHC that is of the same version as the GHC we are building here.
Bump supported LLVM range from 10 through 15 to 11 through 16
LLVM 15 turns on the new pass manager by default, which we have yet to
migrate to so for new we pass the `-enable-new-pm-0` flag in our
llvm-passes flag.
LLVM 11 was the first version to support the `-enable-new-pm` flag so we
bump the lowest supported version to 11.
Our CI jobs are using LLVM 12 so they should continue to work despite
this bump to the lower bound.
GHC 8.10 fails to build on armel with the following error:
LLVM ERROR: unable to allocate function argument #8
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Program arguments: llc-12 -O2 -enable-tbaa -relocation-model=pic -mcpu=arm7tdmi -mattr=+soft-float,-vfp2,-vfp2sp,-vfp3,-vfp3d16,-vfp3d16sp,-vfp3sp,-fp16,-vfp4,-vfp4d16,-vfp4d16sp,-vfp4sp,-fp-armv8,-fp-armv8d16,-fp-armv8d16sp,-fp-armv8sp,-fullfp16,-fp64,-d32,-neon,-crypto,-dotprod,-fp16fml,-bf16,-mve,-mve.fp,-fpregs,+strict-align /tmp/ghc5537_0/ghc_6.bc -o /tmp/ghc5537_0/ghc_7.lm_s
1. Running pass 'Function Pass Manager' on module '/tmp/ghc20177_0/ghc_6.bc'.
2. Running pass 'ARM Instruction Selection' on function '@"stg_gc_f1$def"'
`llc-12' failed in phase `LLVM Compiler'. (Exit code: -6)
make[3]: *** [rts/ghc.mk:325: rts/dist/build/HeapStackCheck.o] Error 1
This patch enables a few native 64-bit integer instructions
on x32 which are available on this architecture despite using
32-bit pointers. These instructions are present on x86_64 but
not on x86 and ghc checks the size of (void *) to determine
that. This method fails on x32 since despite using 32-bit
pointers and hence sizeof(void *) == 4, it still uses the
full x86_64 instruction set and software-emulated variants
of the aforementioned 64-bit integer instructions are
therefore not present in the toolchain which will make ghc
fail to build on x32.
See: https://ghc.haskell.org/trac/ghc/ticket/11571
Jani writes: The D16 part was Debian/Ubuntu specific, IIRC we define hardfloat
in that particular variant (16 double registers) or we had a different naming
for some reason.
[PATCH] llvmGen: Align objects in the data section
Objects in the data section may be referenced via tagged pointers.
Thus, align those objects to a 4- or 8-byte boundary for 32- or 64-bit
platforms, respectively. Note, this may need to be reconsidered if
objects with a greater natural alignment requirement are emitted as e.g.
128-bit atomics.
Peter Trommler [Tue, 7 Nov 2023 20:47:24 +0000 (21:47 +0100)]
[PATCH] PPC NCG: Generate clear right insn at arch width
The clear right immediate (clrrxi) is only available in word and
doubleword width. Generate clrrxi instructions at architecture
width for all MachOp widths.
Previously `ghc-prim`'s atomic wrappers used the legacy `__sync_*`
family of C builtins. Here we refactor these to rather use the
appropriate C11 atomic equivalents, allowing us to be more explicit
about the expected ordering semantics.
Hadrian passes the -DNOSMP flag to GHC when the target doesn't support
SMP, but doesn't pass it to CC as well, leading to the following
compilation error on mips64el:
| Run Cc (FindCDependencies CDep) Stage1: rts/sm/NonMovingScav.c => _build/stage1/rts/build/c/sm/NonMovingScav.o.d
Command line: /usr/bin/mips64el-linux-gnuabi64-gcc -E -MM -MG -MF _build/stage1/rts/build/c/hooks/FlagDefaults.thr_debug_p_o.d -MT _build/stage1/rts/build/c/hooks/FlagDefaults.o -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -Irts/include -x c rts/hooks/FlagDefaults.c -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Winline -Wpointer-arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls -Wundef -fno-strict-aliasing -DTHREADED_RTS -DDEBUG -fomit-frame-pointer -O2 -g -Irts -I_build/stage1/rts/build -DDEBUG -fno-omit-frame-pointer -g3 -O0
===> Command failed with error code: 1
In file included from rts/include/Stg.h:348,
from rts/include/Rts.h:38,
from rts/hooks/FlagDefaults.c:8:
rts/include/stg/SMP.h:416:2: error: #error memory barriers unimplemented on this architecture
416 | #error memory barriers unimplemented on this architecture
| ^~~~~
rts/include/stg/SMP.h:440:2: error: #error memory barriers unimplemented on this architecture
440 | #error memory barriers unimplemented on this architecture
| ^~~~~
rts/include/stg/SMP.h:464:2: error: #error memory barriers unimplemented on this architecture
464 | #error memory barriers unimplemented on this architecture
| ^~~~~
The old make system correctly passed this flag to both GHC and CC [1].
CmmToC: fix CmmRegOff for 64-bit register on a 32-bit target
We used to print the offset value to a platform word sized integer.
This is incorrect when the offset is negative (e.g. output of cmm
constant folding) and the register is 64-bit but on a 32-bit target,
and may lead to incorrect runtime result (e.g. #22607).
The fix is simple: just treat it as a proper MO_Add, with the correct
width info inferred from the register itself.
hs_cmpxchg64 must return a StgWord64, otherwise incorrect runtime
results of 64-bit MO_Cmpxchg will appear in 32-bit unregisterised
builds, which go unnoticed at compile-time due to C implicit casting
in .hc files.
Ilias Tsitsimpis [Mon, 19 Feb 2024 16:12:25 +0000 (17:12 +0100)]
Add more hadrian bootstrap plans
Hadrian only contains bootstrap plans for previous GHC versions. Add plans for
the current version as well, since we may want to bootstrap hadrian with a
cross-compiled GHC that is of the same version as the GHC we are building here.
Bump supported LLVM range from 10 through 15 to 11 through 16
LLVM 15 turns on the new pass manager by default, which we have yet to
migrate to so for new we pass the `-enable-new-pm-0` flag in our
llvm-passes flag.
LLVM 11 was the first version to support the `-enable-new-pm` flag so we
bump the lowest supported version to 11.
Our CI jobs are using LLVM 12 so they should continue to work despite
this bump to the lower bound.
GHC 8.10 fails to build on armel with the following error:
LLVM ERROR: unable to allocate function argument #8
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Program arguments: llc-12 -O2 -enable-tbaa -relocation-model=pic -mcpu=arm7tdmi -mattr=+soft-float,-vfp2,-vfp2sp,-vfp3,-vfp3d16,-vfp3d16sp,-vfp3sp,-fp16,-vfp4,-vfp4d16,-vfp4d16sp,-vfp4sp,-fp-armv8,-fp-armv8d16,-fp-armv8d16sp,-fp-armv8sp,-fullfp16,-fp64,-d32,-neon,-crypto,-dotprod,-fp16fml,-bf16,-mve,-mve.fp,-fpregs,+strict-align /tmp/ghc5537_0/ghc_6.bc -o /tmp/ghc5537_0/ghc_7.lm_s
1. Running pass 'Function Pass Manager' on module '/tmp/ghc20177_0/ghc_6.bc'.
2. Running pass 'ARM Instruction Selection' on function '@"stg_gc_f1$def"'
`llc-12' failed in phase `LLVM Compiler'. (Exit code: -6)
make[3]: *** [rts/ghc.mk:325: rts/dist/build/HeapStackCheck.o] Error 1
This patch enables a few native 64-bit integer instructions
on x32 which are available on this architecture despite using
32-bit pointers. These instructions are present on x86_64 but
not on x86 and ghc checks the size of (void *) to determine
that. This method fails on x32 since despite using 32-bit
pointers and hence sizeof(void *) == 4, it still uses the
full x86_64 instruction set and software-emulated variants
of the aforementioned 64-bit integer instructions are
therefore not present in the toolchain which will make ghc
fail to build on x32.
See: https://ghc.haskell.org/trac/ghc/ticket/11571
Jani writes: The D16 part was Debian/Ubuntu specific, IIRC we define hardfloat
in that particular variant (16 double registers) or we had a different naming
for some reason.
Peter Trommler [Tue, 7 Nov 2023 20:47:24 +0000 (21:47 +0100)]
[PATCH] PPC NCG: Generate clear right insn at arch width
The clear right immediate (clrrxi) is only available in word and
doubleword width. Generate clrrxi instructions at architecture
width for all MachOp widths.
projects / ghc.git / log